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' LISTING RECOMMENDATION IN A NETWORK-BASED COMMERCE 

SYSTEM 

CROSS REFERENCE TO RELATED APPLICATION 

[0001] The present application claims the benefit of the filing date of 
U.S. provisional application serial no. 60/420,199, filed October 21, 2002. 

FIELD OF THE INVENTION 

[0002] The present invention relates generally to the field of electronic 
commerce, and more specifically to a method and system for generating listing 
recommendations to a user of a network-based commerce system. 

BACKGROUND 

[0003] More and more Internet users are realizing the ease and 
convenience of buying and selling online via a network-based commerce system. 
Certain such commerce systems are focused on person-to-person trading, and 
collectors, hobbyists, small dealers, unique listing seekers, bargain hunters, and 
other consumers, are able to buy and sell millions of listings at various online 
shopping sites. Such systems also support business-to-person and business-to- 
business commerce. 

[0004] The success of a networked-based commerce system may 
depend upon its ability to provide a user-friendly environment in which buyers 
and sellers can conduct business efficiently. Current network-based commerce 
systems have certain limitations in the manner in which they present information 
to users. 
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SUMMARY OF THE INVENTION 

[0005] According to one aspect of the invention, there is provided a 
method to facilitate generating listing recommendations to a user of a network- 
based commerce system. In one embodiment, the method includes identifying a 
term associated with a user interaction in a network-based commerce system. 
The method further includes generating a recommendation query including the 
identified term. In addition, the method includes running the recommendation 
query against a plurality of listings hosted by the network-based commerce 
system to identify a recommendation. Moreover, the method includes 
presenting the recommendation to a user of the network-based commerce 
system. 

[0006] Other features of the invention will be apparent from the 
accompanying drawings and from the detailed description that follows. 



3 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] The invention is now described, by way of example, with 
reference to the accompanying diagrammatic drawings in which like reference 
numerals are used to indicate the same or similar features, unless otherwise 
indicated. 

Figure 1 is block diagram illustrating an exemplary network-based 
commerce system, in accordance with an aspect of the invention. 

Figure 2 is a database diagram illustrating an exemplary database, 
maintained by and accessed via a database engine server, which at least partially 
implements and supports the network-based commerce system. 

Figures 3A and 3B are an exemplary listings and user tables of the 
database. 

Figure 4 is exemplary logic, in accordance with the invention, for 
generating recommendation queries. 

Figure 5 is an exemplary schematic flow diagram of a method, in 
accordance with the invention, for generating recommendation queries. 

Figure 6 is an exemplary schematic flow diagram of a method, in 
accordance with the invention, of determining popular search terms for selected 
categories of listings of the network-based commerce system. 

Figure 7 is an exemplary flow diagram of a method, in accordance with 
the invention, of identifying matching possible phrase- or term-category pairs 
associated with unique listings bid on (and /or viewed and /or bought) by a user 
of the network-based commerce system. 

Figure 8 is an exemplary flow diagram of a method, in accordance with 
the invention, of ranking term-category pairs. 
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Figure 9 is a schematic illustration of an exemplary category node tree, in 
accordance with the invention, for determining a popularity threshold of a term- 
category pair. 

Figure 10 is an exemplary flow diagram of a method, in accordance with 
the invention, of determining a relative upper popularity boundary of a listing 
associated with a term-category pair. 

Figures 11A and 11B show an exemplary flow diagram of a method, in 
accordance with the invention, of running a recommendation query. 

Figure 12 is a schematic representation of an exemplary listing 
recommendation table of the database. 

Figure 13 is an exemplary graphic user interface providing recommended 
listings to the user. 

Figures 14A-14F are exemplary data structures utilized in the generation 
of recommendation queries, according to an exemplary embodiment of the 
invention. 

Figure 15 shows a diagrammatic representation of machine in the 
exemplary form of a computer system within which a set of instructions, for 
causing the machine to perform any one of the methodologies discussed herein, 
may be executed. 
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DETAILED DESCRIPTION 

[0008] A method and system automatically to recommend listings in a 
network-based commerce system based on past user behaviour is described. In 
the following description, for purposes of explanation, numerous specific details 
are set forth in order to provide a thorough understanding of the invention. It 
will be evident, however, to one skilled in the art that the invention may be 
practiced without these specific details. 

Terminology 

[0009] For the purposes of the present specification, the term "listing" 
or "item" may refer to any description, identifier, representation or information 
pertaining to a listing, service, offering or request that is stored within a network- 
based commerce system. As such, a listing may be an auction or fixed-price 
offering (e.g., products such as goods and/or services), an advertisement, or a 
request for a listing or service. The term "listing recommendation" may include 
an instance of a listing being presented by a network-based commerce system. 
The term "popular search term" may include any criteria, textual, numeric, 
visual, audible or otherwise, frequently submitted by users searching a network- 
based commerce system. For the purposes of this specification, the word "term" 
is synonymous with the word "phrase" and is also intended to include a 
plurality of words. Thus, "term" or "phrase" can be used to refer to any entry (or 
entries) a user enters into a search field when requesting a search of the network- 
based commerce system. The term "recommendation query" may include a 
query that is run to produce one or more listing recommendations. The term 
"term-category pair" (or phrase-category pair) may refer to a popular search 
term or phrase associated with a particular category. In one embodiment, the 
term-category pair is used to generate a recommendation query. The term 
"popularity threshold" may include a minimum rank that a popular search term 
must hold in a category to be considered sufficiently popular to be used in a 
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recommendation query. The term "relative popularity boundary" may include a 
measurement of the limit for a popular search term from a particular starting 
point through a category structure. The term "show me more" link may include 
any link placed next to a listing recommendation in the network-based 
commerce system. In one embodiment, activating the link will execute a database 
query in real time using a recommended popular search term to locate all current 
listings associated with the popular search term. Thus, the "show me more" link 
may provide additional listing recommendations to a specific user. 

Transaction Facility 

[00010] Figure 1 is block diagram illustrating an exemplary network- 
based commerce system 10. While an exemplary embodiment of the present 
invention is described within the context of the network-based commerce system 
10, the invention will find application in many different types of computer- 
based, and network-based, facilities (commerce, transaction or otherwise). 

[00011] The network-based commerce system 10, includes one or more 
of a number of types of front-end servers that each includes at least one Dynamic 
Link Library (DLL) to provide selected functionality. The system 10 includes 
page servers 12 that deliver web pages (e.g., mark-up language documents), 
picture servers 14 that dynamically deliver images to be displayed within Web 
pages, listing servers 16 that facilitate category-based browsing of listings, search 
servers 18 that handle search requests to the system 10 and facilitate keyword- 
based browsing of listings, and ISAPI servers 20 that provide an intelligent 
interface to a back-end of the system 10. The system 10 also includes e-mail 
servers 22 that provide, inter alia, automated e-mail communications to users of 
the network-based commerce system 10. In one embodiment, one or more 
administrative application functions 24 facilitate monitoring, maintaining, and 
managing the system 10. One or more API servers 26 may provide a set of API 
functions for querying and writing to the network-based commerce system 10. 
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APIs may be called through the HTTP transport protocol. In one embodiment, 
information is sent and received using a standard XML data format. 
Applications utilized to interact (e.g., upload transaction listings, review 
transaction listings, manage transaction listings, etc.) with the network-based 
commerce system 10 may be designed to use the APIs. Such applications may be 
in an HTML form or be a CGI program written in C++, Perl, Pascal, or any other 
programming language. Exemplary APIs are more fully described in co-pending 
U.S. Patent Application 09/999,618, herein incorporated by reference. 

[00012] The page servers 12, API servers 26, picture servers 14, ISAPI 
servers 20, search servers 18, e-mail servers 22 and a database engine server 28 
may individually, or in combination, act as a communication engine to facilitate 
communications between, for example, a client machine 30 and the network- 
based commerce system 10. In addition, the page servers 12, API servers 26, 
picture servers 14, ISAPI servers 20, search servers 18, e-mail servers 22 and 
database engine server 28 may individually, or in combination, act as a 
transaction engine to facilitate transactions between, for example, the client 
machine 30 and the network-based commerce system 10. Furthermore, the page 
servers 12, API servers 26, picture servers 14, ISAPI servers 20, search servers 18, 
e-mail servers 22 and database engine server 28 may individually, or in 
combination, act as a display engine to facilitate the display of listings on, for 
example, the client machine 30. 

[00013] The back-end servers may include the database engine server 
28, a search index server 32 and a credit card database server 34, each of which 
maintains and facilitates access to a respective database. 

[00014] In one embodiment, the network-based commerce system 10 is 
accessed by a client program, such as for example a browser 36 (e.g., the Internet 
Explorer distributed by Microsoft Corp. of Redmond, Washington) that executes 
on the client machine 30 and accesses the network-based commerce system 10 
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via a network such as, for example, the Internet 38. Other examples of networks 
that a client may utilize to access the network-based commerce system 10 include 
a wide area network (WAN), a local area network (LAN), a wireless network 
(e.g., a cellular network), the Public Switched Telephone Network (PSTN) 
network, or the like. The client program that executes on the client machine 30 
may also communicate with the network-based commerce system 10 via the API 
servers 26. 

Database Structure 

[00015] Figure 2 is a database diagram illustrating an exemplary 
database 40, maintained by and accessed via the database engine server 28, 
which at least partially implements and supports the network-based commerce 
system 10. In one embodiment, the database engine server 28 may maintain two 
databases, a first database being maintained for listing (or offering) information 
that is not included within a virtual // store ,/ , and a second database for listing (or 
offering) information that is presented via a virtual "store" supported by the 
network-based commerce system 10. 

[00016] The database 40 may, in one embodiment, be implemented as a 
relational database, and includes a number of tables having entries, or records, 
that are linked by indices and keys. In an alternative embodiment, the database 
40 may be implemented as collection of objects in an object-oriented database. 

[00017] The database 40 (see Figure 2) includes a user table 42 that 
contains a record for each user of the network-based commerce system 10. An 
exemplary record for each user is shown in Figure 3B. A user may operate as a 
seller, a buyer, or both, when utilizing the network-based commerce system 10. 
The database 40 also includes listings tables 44 that may be linked to the user 
table 42. The listings tables 44 may include a seller listings table 46 and a bidder 
listings table 48. A user record in the user table 42 may be linked to multiple 
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listings that are being, or have been, listed or offered for sale via the network- 
based commerce system 10. In one embodiment, a link indicates whether the 
user is a seller or a bidder (or buyer) with respect to listings for which records 
exist within the listings tables 44. 

[00018] The database 40 also includes one or more divisions in the form 
of categories provided in category tables 50. Each record within the category 
table 50 may describe a respective category. In one embodiment, listings 
provided by the system 10 are arranged in the categories. These categories may 
be navigable by a user of the network-based commerce system 10 to locate 
listings in specific categories. Thus, categories provide a mechanism to locate 
listings that may be browsed. In addition or instead, an alphanumeric search 
mechanism may be provided by the search servers 20 to allow a user to search 
for specific listings using search terms or phrases. In one embodiment, the 
category table 50 describes multiple, hierarchical category data structures, and 
includes multiple category records, each of which describes the context of a 
particular category within the multiple hierarchical category structures. For 
example, the category table 50 may describe a number of real, or actual, 
categories to which listing records, within the listings tables 44, may be linked. 

[00019] The database 40 also includes one or more attributes tables 52. 
Each record within the attributes table 52 describes a respective attribute 
associated with a listing. In one embodiment, the attributes table 52 describes 
multiple, hierarchical attribute data structures, and includes multiple attribute 
records, each of which describes the context of a particular attribute within the 
multiple hierarchical attribute structures. For example, the attributes table 52 
may describe a number of real, or actual, attributes to which listing records, 
within the listings tables 44, may be linked. Also, the attributes table 52 may 
describe a number of real, or actual, attributes to which categories, within the 
category table 50, may be linked. 
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[00020] The database 40 may also include a note table 54 populated with 
note records that may be linked to one or more listing records within the listings 
tables 44 and /or to one or more user records within the user table 42. Each note 
record within the note table 54 may include, inter alia, a comment, description, 
history or other information pertaining to a listing being offered via the network- 
based commerce system 10, to a user of the network-based commerce system 10. 
The database 40 may also include a targeted site table 56 populated with targeted 
site records that may be linked to one or more listing records within the listings 
tables 44 and/or to one or more user records within the user table 42. 

[00021] A number of other exemplary tables may also be linked to the 
user table 42, namely a user past aliases table 58, a feedback table 60, a feedback 
details table 62, a bids table 64, an accounts table 66, and an account balances 
table 68. In one embodiment, the database 40 also includes a batch table 70, a 
batch listings table 72, and a listings wait table 74. 

[00022] In one embodiment, the system 10 generates listing 
recommendations to a user of the system 10. The listing recommendations may 
be based on past user interaction of the particular user with the system 10, and 
popular search terms used in the network-based commerce system 10 (or any 
other systems associated with the network-based commerce system 10). 

[00023] Referring in particular to Figure 4, reference numeral 80 
generally indicates exemplary logic for generating recommendation queries 
based on past user interaction in the form of past bidding (and/or buying) 
history of the user, and the popular search terms. As shown at block 82 past 
bidding (and /or buying) data of participating users is gathered at a data 
warehouse. In addition, popular search terms or phrases are gathered at block 84 
that, together with the past bidding (and /or buying) data is used to generate 
recommendation queries (see block 86). Thus, the data warehouse may identify 
and store search terms that are used most frequently (popular search terms) 
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across one or more predetermined number of sites (e.g., web sites) associated 
with the network-based commerce system 10, and also identify data uniquely 
associated with each user. As shown at block 88, the popular search terms may 
then be passed periodically (e.g., on a daily basis) to a production facility, where 
the production facility may then project the popular search data against current 
listing inventory (see block 90). In one embodiment, a search is conducted 
through each category, at each category level, using each popular search term. 
All popular search terms that match at least a predetermined number of listings 
(e.g., 50 listings), located in each particular category, may be stored along with 
total number of listings located in the particular category using the popular 
search term. Thus, each category may have a number of popular search terms or 
phrases (e.g., from 0 to a predetermined number) assigned to it along with a 
measurement of the popularity of the search term in that category. Thus, the 
system 10 allows a search to be conducted through current listings based on 
popular searches (based on interaction of all users) and unique historical 
interaction of an individual user. 

[00024] Referring to Figure 5, reference numeral 100 generally indicated 
an exemplary method, in accordance with the invention, for generating 
recommendation queries based on past user interaction in the form of past 
bidding (and/ or buying) history of the user, and popular search terms. The 
method may be carried out at the production facility and broadly include the 
following operations: 

1. Select user for which recommendation queries will be generated; 

2. Identify at least one listing that has been interacted with by the user 
during a time period; 

3. Determine a corresponding category associated with each 
identified listing and a title of each listing; 
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4. Find popular search terms associated with each corresponding 
category; 

5. Rank each popular search term found; 

6. Determine best term-category pairs; 

7. Determine a relative popularity boundary for each term-category 
pair; and 

8. Construct the actual recommendation queries; 

[00025] The above exemplary operations are described in more detail 
with reference to Figure 5. As shown at block 102, the method 100 selects prior 
listings (which may or may not have terminated) that the user has bid on, for 
example, listings (e.g., products such as goods and/or services) that the user has 
bid on in the last predetermined number of days or hours (e.g., the last 24 hours). 
Thereafter, the method 100 identifies a corresponding category associated with 
each prior listing and identifies the title of each listing (see block 104). 

[00026] As shown at block 106, the method 100 also identifies popular 
search terms (terms frequently used by users) associated with each 
corresponding category (or sub-category). This operation may produce one or 
more popular search terms or phrases that are indirectly derived from listings 
the user has previously interacted with. 

As multiple popular search terms may be associated with each category, the 
method 100 at block 108 ranks the popular search terms based on the title for 
each selected listing, as will be described in more detail below. 

[00027] Once the popular search terms have been ranked (see block 108) 
and the category and title for each listing have been identified (see block 104), the 
method 100 compares the item title to popular search terms also found in the title 
(see block 110). Thereafter, the method 100 may identify all popular search terms 
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also found in the title (see block 111). At this point in the method 100, a term- 
category pair may thus be provided for each category (which was derived from 
the listings that the user previously interacted with). 

[00028] At block 112, the method may choose the highest ranked term- 
category pair based on overall popularity of the search term.. Thereafter, a 
popularity threshold (e.g., the highest category level) for each term-category pair 
is determined (see block 114). A recommendation query is constructed at block 
116 based on recommendation criteria. The recommendation query is then saved 
at block 118 for communication to a production facility. 

[00029] In summary, the method 100 may be used to construct a 
recommendation query (e.g., a search string) that when run, for example against 
the database 40, may locate listings based on previous unique user interaction 
with the system 10 as well as popular search terms used by other users at large. It 
will be appreciated that the functionality described in the various blocks 102 to 
118 need not be performed as separate operations and the functionality in some 
of the blocks may be combined into a single operation. 

[00030] The method 100 for generating recommendation queries may be 
run periodically. In order to take into account recent changes in the user's 
bidding (and /or purchasing) behaviour it may be advantageous to run the 
recommendation queries as frequently as possible. 

[00031] Referring in particular to Figure 6, reference numeral 120 
generally indicates a method, in accordance with the invention, of determining 
popular search terms for selected categories of listings of the network-based 
commerce system 10. The method 120 may, for example, be used in the 
operation described in block 106 of Figure 5. The generation of the popular 
search terms is more fully described in co-pending U.S. Provisional Patent 
Application 60/482,605 entitled "PRODUCT RECOMMENDATION IN A 
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NETWORK-BASED COMMERCE SYSTEM FILED ON June 25, 2003. The 
content of the co-pending application is incorporated herein by reference. 

[00032] At block 122, a first category associated with the network-based 
commerce system 10 is selected. As mentioned above, this category may be a 
category corresponding to listings previously bid on by the user (see blocks 102 
and 104 of Figure 5). Thereafter, a library or store of popular search terms is 
accessed to retrieve a first popular search term associated with the selected (first) 
category (see block 124). The first popular search term is then compared against 
each listing in the first category to identify the number of listings in the selected 
(first) category located (see block 126). A check is then done at decision block 128 
to determine if the selected (first) popular search term matches or locates at least 
a predetermined number of listings in the selected (first) category. If the 
predetermined number of listings is located, then the selected (first) popular 
search term and the identity of the selected (first) category are stored to a 
popular search table 130 (see block 132 and Figure 14A). The method 120 then 
proceeds to decision block 134. If, however, the predetermined number of 
listings is not located, then the method 120 proceeds directly from decision block 
128 to decision block 134 without storing the selected (first) popular search term. 

[00033] At block 134, a decision is made as to whether or not all popular 
search terms associated with the selected (first) category have been retrieved. If 
not, then at block 136, the next (second) popular search term associated with the 
selected (first) category is retrieved. The method 120 then returns to block 126 
and executes the functionality described above until all popular search terms 
associated with the selected (first) category have been retrieved and considered. 
Accordingly, as shown at decision block 134, when all the popular search terms 
associated with the selected (first) category have been retrieved, the method 120 
proceeds to decision block 138 to perform the abovementioned functionality on 
the next selected (second) category. If all categories have not yet been considered, 
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the method 120 proceeds to block 140 where the next category associated with 
the user interaction is selected and the selected (first) popular search term is 
retrieved from the popular search term table 130 (see block 142). The method 120 
then proceeds to block 126 to execute the functionality described above on the 
selected (second) category. As shown at block 138, the above functionality is 
carried out until all categories derived from the user interaction have been 
considered, whereupon the method 120 terminates. 

[00034] Referring in particular to Figure 7, reference numeral 150 
generally indicates a method, in accordance with the invention, of identifying 
and ranking phrase- or term-category pairs associated with unique listings bid 
on (and /or viewed and /or bought) by a user of the network-based commerce 
system 10. The method 150 may be carried out in blocks 102, 104, and 108 in 
Figure 5. 

[00035] As shown at block 152, a user may be selected to receive a 
recommendation query that, when run, generates listing recommendations 
tailored to the specific user. However, it is to be appreciated that any one or 
more users of the network-based commerce system may receive listing 
recommendations. According, as shown at decision block 154, an enquiry is 
made whether or not a user has opted out of receiving listing recommendations 
and, if so, the method 150 then terminates at block 156. However, if the user has 
opted in, the method 150 proceeds to decision block 158 to determine if any 
activity (e.g., interaction with listings of the network-based commerce system 10) 
related to the user has taken place since the method 150 was previously executed 
for the user. If no activity (e.g., purchasing of listings, bidding on listings, 
viewing of listings, etc.) has occurred since the user's recommendation queries 
were previously updated, then the method 150 terminates at block 156. 

[00036] Thus, in one embodiment, recommendation queries may be 
recalculated for each user when necessary (e.g., the user is active 
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bidder/purchaser). For example, if the process of generating new 
recommendation queries fails, or cannot be completed for some reason, the 
queries previously generated may become stale or inappropriate. However, 
even if stale, recommendation queries may continue to be used to generate 
recommended listings when run against current listings. Thus, even though the 
recommendation query itself is stale, when the current listings (to which new 
listings may be constantly added and terminated listings may be removed) are 
searched using the stale recommendation query, different recommended listings 
may be provided to the user. Thus, it is important to note that although the 
recommendation query or queries may not have been updated, they may still be 
run as often as the network-based commerce system 10 determines necessary. 
Each time the queries are run, new results may be yielded. Such new results 
reflect the unpredictability of inventory supply and demand in the network- 
based commerce system 10. In one embodiment, a subsequent attempt to 
generate a recommendation query for a user, where a previous attempt has 
failed, should take the time period considered in the pervious attempt into 
account. For example, assuming the process checks whether a user has placed a 
new bid in the last 24 hours. If the recommendation process fails, then the next 
time the recommendation process is run, it should check for bids within the last 
48 hours. 

[00037] Returning to block 158, if user activity during a selected time 
window has taken place, then at block 160 the method 150 may then generate 
listing recommendations unique to the user. In one embodiment, the method 100 
(see Figure 5) is executed in block 160. 

[00038] In one embodiment, where listings are arranged in hierarchical 
structure having parent and child categories, unique listings (e.g., listings during 
a predetermined period, e.g., 30 days) that the user has interacted with are 
retrieved from a Bid Listing and Parent Category table 162 (see block 102 in 
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Figure 5 and Figure 14B). When the listings are items, the Bid Listing Category 
table 162 may include a UserJD field, an ItemJ3id_On_ID field, an 
Item_Bid_On_Title field, and an Item_Bid_On_Parent_Category field. 

[00039] Further, for each of the identified unique listings, a primary 
parent level category (e.g., a highest level category in the hierarchical category 
structure) may be identified (see also block 104 in Figure 5). Based on the 
primary parent level category, popular search terms may be identified (see also 
block 106 in Figure 5) that are associated with the primary parent level category. 
In one embodiment, all of the identified popular search terms associated with 
each of the identified unique listings are compared against all listings in the 
primary parent level category to determine if any of the popular search terms 
match any portion of a title of a corresponding listing in the primary parent level 
category. 

[00040] In one embodiment, popular search terms are ranked (see block 
108 in Figure 5) according to their popularity (number of corresponding listings) 
per parent level category. For a specific listing's parent level category, each of 
the popular search terms identified are run against all the listings in the category 
and a count associated with each popular search term is incremented each time 
the popular search term matches any portion of a title of a listing. A temporary 
list of the popular search terms and their associated count (indicating the number 
of times the popular search term matched a portion of a listing title) may be 
maintained in a descending order of popularity. For each of the identified listings 
and their associated parent level category, the most popular of the matching 
popular search terms (e.g., first popular search term in the list) is selected and 
stored in a Matching Popular Search Term table 164 (see Figure 14C). When the 
listings are items, the Matching Popular Search Term table 164 may include a 
UserJD field, an Item_Bid_On_ID field, an Item_Bid_On_Title field, an Item 
_Bid_On_Parent_Category field, and a Popular_Search_Term_Match field. 
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[00041] In one embodiment, all unique listings up to a predetermined 
number (e.g., 20) that the user has interacted with in the predetermined or 
selected time period (e.g., 30 days) may be chosen. In one embodiment, the 
following two types of listings are be ignored when generating recommendation 
queries: 

• Listings listed in banned categories based on a user's site of 
registration; and 

• Listings listed for mature audiences. 

[00042] In one embodiment, there may be multiple country sites (e.g., 
U.S., U.K., DE, etc.) associated with the network-based commerce system 10. For 
purposes of generating recommendation queries, listings to be recommended 
may be chosen from any of the country sites associated with the network-based 
commerce system 10. Accordingly, in one embodiment, no listing is ignored 
because it was listed on a different country site than that which the user is 
registered on. Of course, in an alternative embodiment the user may specify that 
listings only be recommended from a selected site or sites. 

[00043] Popular search terms that have been ranked may be stored in a 
Ranked Matching Term table 166 (see Figure 14D). The Ranked Matching Term 
table 166 may include a User JD field, an Item_Bid_On_ID field, an 
Item_Bid_On_Parent_Category field, a Popular_Search_ Term field, and a 
Popular_Search_ Term_Ranking field. 

[00044] As mentioned above, a list of the highest ranked popular search 
terms in the parent level category may be used to generate listing 
recommendations. In one embodiment, a configurable value may determine a 
"popularity threshold". This value may be a lowest rank within a given category 
that a popular search term must have to be considered "popular enough" for the 
purposes of creating recommendation queries in the network-based commerce 
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system 10. For example, there may be 40 terms or phrases that are considered in 
a category, but the popularity threshold may be set to 25 so that only the top 25 
search terms within that category are used. The popular search terms may be 
retrieved from a Popular Search Term table 130 (see Figure 14 A). 
Recommendation queries for each user may stored in a Recommendation Query 
table 168 (see Figure 14E) that includes a UserJD field, an 
Item_Bid_On_Category field, a Popular_Search_ Term field, and a 
Relative_Upper_Boundry field. When the recommendation query is run against 
current inventory, recommended listings for the particular user may be uniquely 
generated and stored, for example, in a Recommendation table 170 (see Figure 
14F). 

[00045] As mentioned above (see block 110 in Figure 5), the method 100 
may select the most popular search term associated with each category thereby 
selecting term-category pairs. An exemplary method 180, also in accordance with 
the invention, to choose the best term-category pairs is shown in Figure 8. At 
block 182, term-category pairs are retrieved from the Matching Popular Search 
Term table 164. The term-category pairs retrieved may only be those for the 
specific user that a recommendation query or queries is being generated for. In 
one embodiment, the term-category pairs retrieved may be required to meet one 
or more of the following exemplary criteria: 

• The term-category pairs are relevant in the categories associated with a 
listing that the user was bidding on; 

• The term-category pairs match actual titles of listings the user has bid 
on; and/or 

• The term-category pairs represent the unique and /or interesting 
qualities of those listings. 

[00046] In order to avoid duplication, at block 184, duplicates of any of 
the term-category pairs are removed (e.g., the record may be deleted). For 
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example, a user may have bid on two Norelco razors, each generating a term- 
category pair for "Norelco" in "Electric Shavers/ 7 This duplication may then be 
removed at block 184. 

[00047] Once any duplicates have been removed, at block 186 each 
term-category pair is ranked based on the overall popularity of the relevant 
search term across the entire network-based commerce system 10 (and any 
associated sites which may be included). The most popular search term may 
then be given a rank of 1, the next most popular may be given a rank of 2, and so 
on until all popular search terms have been ranked. Thereafter, at block 188, a 
configurable value relative to the maximum number of recommendation queries 
per user is determined. The configurable value may be used to determine the 
cut-off point or popularity threshold of the popular search terms or term- 
category pairs. In one embodiment, if the user has fewer term-category pairs 
than the maximum number of recommendation queries allowed per user, then 
all of the term-category pairs in the Popular Search Term table 130 may be used. 

[00048] At block 190, the highest ranked term-category pairs up to the 
maximum number of recommendation queries per user are selected. Thereafter, 
at block 192, the term -category pairs selected at block 190, and each of their 
respective rankings, are stored in the Ranked Matching Term table 166. Each of 
the term-category pairs stored in the Ranked Matching Term table 166 may then 
be used to produce a recommendation query as described herein. 

[00049] Reference numeral 200 (see Figure 10) generally indicates a 
method, in accordance with the invention, for determining a popularity 
threshold or upper boundary of a term-category pair. The method 200 is 
described with reference to an exemplary category node tree 202 (see Figure 9), 
also in accordance with the invention. The method 200 may be used in deciding 
the popularity threshold as described in block 114 of Figure 5. As the 



21 



recommendation queries are based on user interaction with the system 10, they 
are related to the buyer's interests. 

[00050] Referring in particular to Figure 9, the category node tree 202 
shows an exemplary data structure in which each node may be attached to one 
or more nodes directly beneath it. Branches 206 may interconnect the nodes. An 
example of a listing 208 and a relative lower popularity boundary 210 of an 
associated term-category pair and a relative upper popularity boundary 212 of 
the term-category pair are shown. The space between the relative lower 
popularity boundary 210 and the relative upper popularity boundary 212 may be 
referred to as a "universe of possible recommendations" 214. The universe of 
possible recommendations 214 may also be referred to as a relative footprint of 
possible recommendations. 

[00051] Returning to method 200 (see Figure 10) of determining the 
relative upper boundary of the term-category pair. Previously, as described 
above, the method 180 (see Figure 8) ranked and stored term-category pairs 
associated with a unique listing with which the user has interacted (see Figure 
14D). The Item_Bid_On_Parent_Category field may indicate the parent category 
of the unique listing and, in certain embodiments, may define the unique listing's 
relative lower popularity boundary 210 (see Figure 9). The method 200 may then 
be utilized to determine the relative upper popularity boundary 212 (see Figure 
9). 

[00052] In order to determine the relative upper popularity boundary 
212, at block 216 the first term-category pair associated with a specific user is 
selected from the Ranked Matching Term table 166 (see Figure 14D). Thereafter, 
at decision block 218, a determination is made as to whether or not a node is a 
root level node (the node at a highest level in category node tree 202). If the node 
is not a root level node, at decision block 222 a determination is made as to 
whether or not the term-category pair meets the popularity threshold in the next 
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higher level node 224 of the category node tree 202. If the term-category pair 
meets the popularity threshold at the next node 224, then the next higher level 
node 228 in the node tree 202 is selected at block 230 and the method 200 returns 
to decision block 218. In the present example, the term-category pair is shown to 
meet the popularity threshold at the node 228 and, accordingly, the method 200 
also considers the next higher level node 232. If, however, the term-category pair 
does not meet the popularity threshold at the next node (in the present example 
node 232) then at block 234, the current node (node 228 in the present example) is 
selected and stored as the relative upper boundary in the exemplary 
Recommendation Query table 168 (see Figure 14E). As shown at decision block 
236, if all term-category pairs have not been processed, then the method 200 at 
block retrieves the next phrase-category pair and proceeds to decision block 218. 
Once all term-category pairs have been processed, the method 200 terminates at 
block 240. 

[00053] Thus, according to method 200, if the term-category pair meets 
the popularity threshold in the current category, the next highest node in the 
category node tree is selected. The process of sequentially moving up the 
category tree (see block 230) continues until the term-category pair no longer 
meets the popularity threshold or a root level node has been reached. As 
described above, when the root level node (e.g., the node 232) is reached or the 
term-category pair does not meet the popularity threshold in the next node up 
the node tree 202, then the current node is stored as the relative upper popularity 
boundary to the Recommendation Query table 168. 

[00054] Referring in particular to Figures 11A and 11B, reference 
numeral generally indicates a method, in accordance with the invention, of 
running a recommendation query to generate recommendation listings. In one 
embodiment, the recommendation query is a set of instructions to locate a listing 
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from a plurality of listings, utilizing a popular search term and its relative 
popularity boundaries 210, 212. 

[00055] At block 252, a first term-category pair and its associated 
relative popularity boundaries (e.g., relative upper popularity boundary 212 and 
relative lower popularity boundary 210) are retrieved. The upper popularity 
boundary 212 may be retrieved from the Recommendation Query table 168, and 
the lower popularity boundary 210 may be provided by the 
Item_BidJ3n_JParent_Category field of the Ranked Matching Term table 166. 
Thus, in certain embodiments, the relative lower popularity boundary 210 may 
be derived from a listing that the user previously interacted with. 

[00056] Thereafter, at block 254 all listings between the relative lower 
popularity boundary 210 and relative upper popularity boundary 212 of the 
retrieved term-category pair are searched to locate listings identified by the term- 
category pair (in other words a popular search term that has been identified and 
processed by the method 100). 

[00057] At decision block 254, a determination is made as to whether a 
match is found and, thus, if any listings (items) have been found in the universe 
of possible recommendations 214 (see Figure 9). If no match or listings are 
found, then at decision block 256 a determination is made to check if all term- 
category pairs have been searched. If all term-category pairs have been searched, 
then the method 250 terminates at 258. However, if more term-category pairs are 
to be searched, as shown at block 260 the next term-category pair is retrieved 
whereafter the method 250 returns to block 254 to execute the abovementioned 
functionality for the next tem-category pair. 

[00058] Returning to block 254, if a match is found, and thus a listing 
identified by the term-category pair has been located, then a filter process is 
performed to filter out or reject selected listings. For example, at decision block 
262, listings for mature audiences are filtered out or rejected, at decision block 
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264 banned listings are rejected, at block 266 listings which would not be located 
using the term-category pair are rejected, at decision block 268 listings with a 
listing time close to ending (or already ended) may be rejected, at decision block 
270 listings with more time remaining than a minimum time left are rejected, and 
at decision block 272 listings not available to a user of a site the user is registered 
in may be rejected. For example, rules of the network-based commerce system 10 
my restrict user access to certain listings and/or sites. It is however, to be 
appreciated that the aforementioned filter criteria may be supplemented, 
reduced, changed in various different embodiments. In one embodiment, the 
minimum time left for listing recommendations is a configurable value. Thus 
recommendations may not be made for listings that have so little time remaining 
that the buyer cannot be expected to make a decision to interact (e.g., bid, 
purchase, make inquiries, etc.) with the listing before it ends. 

[00059] The listings located using the term-category pair are ranked at 
block 274 and thereafter stored in the Recommendation table 170 (see Figure 14F) 
as shown at block 276. As mentioned above, the functionality in the method 250 
is carried out on all term-category pairs and, accordingly, at decision block 278 a 
determination is made to check if all term-category pairs have been processed. If 
all term-category pairs have not been processed, then the method 250 proceeds to 
block 260 (see Figure 11 A). However, if all term-category pairs have been 
processed, then at block 280 the method 250 ends. 

[00060] Each listing is the recommendation table (see Figure 14F) may 
be ranked according to a predetermined set of configurable criteria. For 
example, in one embodiment, listings including an image of the listing that a 
user may view may be ranked higher than listings without an image. If the 
listings are equally ranked, a configurable value may determine, for example, 
whether listings ending sooner or listings listed most recently will be ranked 
higher. 
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[00061] In certain embodiments, it may be desirable to generate 
recommended listings that are not the same (or substantially similar) to listings 
the user has already been interacting with (e.g., bid or bidding on, viewed, 
purchased, etc.). Accordingly, in one embodiment, recommendation queries 
may produce results outside the category (or categories) associated with the 
listings that the user has interacted with. 

[00062] For example, a user may have purchased a listing for a CD from 
a "Rock" category wherein a matching popular search term for that listing is 
"Melissa Etheridge." Listing recommendations corresponding to or matching 
"Melissa Etheridge" may however be drawn from multiple categories. For 
example, in generating recommended listings, listings from the "Rock" category 
could be excluded, or all CDs could be excluded and something else entirely 
could be presented to the user. In the current example, using "Melissa 
Etheridge", since Melissa Etheridge CDs may also be commonly found in 
Country CDs, the entire CD category may be ignored. Ignoring the entire CD 
category may be accomplished by recognizing that "Melissa Etheridge" is still 
relatively popular even in the entire category of CDs. However, outside the CD 
category, the term "Melissa Etheridge" may no longer ranked as high in 
popularity. Therefore, the relative lower popularity boundary of "Melissa 
Etheridge" may be defined as the CD category. Thus, in this example, all listings 
falling within the CD category may be excluded in the recommendation query. 

[00063] As mentioned above, each recommendation query may 
produce multiple recommended listings. Figure 12 shows an exemplary listing 
recommendation table 290 for storing three recommendation queries and five 
recommended listings or items generated from each one of the three 
recommendation queries. The recommended listings may then be displayed via a 
graphic user interface 292 (see Figure 13). The graphic user interface 292 may 
form part of a larger user interface and, in Internet applications of the network- 
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based commerce system 10, the graphic user interface 292 may be a web page. 
The graphic user interface 292 includes five rows 294 to 302 that each displays a 
recommended listing to the user. The recommended listings may include 
hyperlinks to further details on the recommended listing. 

[00064] The graphic user interface 292 may be populated from the 
recommendation table 290. In particular, the recommendation table 290 includes 
three columns for each of the recommendation queries. Accordingly, column 394 
stores five recommended listings 310 to 318 associated with the first 
recommendation query, column 306 stores five recommended listings 320 to 328 
associated with the second recommendation query, and column 308 stores five 
recommended listings 330 to 338 associated with the third recommendation 
query. The recommended listings in the columns 304 to 308 are generated by 
searching all current listings using search strings 340 to 344 associated with the 
first, second and third recommendation queries, respectively. 

[00065] Rows 346 to 354 are populated by sequentially selecting items or 
listings from the columns 304 to 308 and their associated recommendation query 
data. The graphic user interface 292 may then be populated from the rows 346 to 
354. 

[00066] The number of recommendation queries and/or recommended 
listings may differ from one embodiment to the next. Each recommendation 
query may thus produce a finite number of recommendations, equal to the 
number of listing recommendations to be displayed to a user. While the 
recommendation query may not always reflect the most recent activity of the 
user, in one embodiment the network-based commerce system 10 is configured 
so that the actual listings returned from the recommendation query are up to 
date (e.g., correct price, listing's time remaining). 

[00067] In certain embodiments, the graphic user interface 292 is only 
displayed to a user of the network-based commerce system that has opted to 
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receive recommended listings. In one embodiment, the network-based 
commerce system 10 only provides recommended listings to the user when there 
has been sufficient past interaction by the user, with the network-based 
commerce system 10, to support the generation of recommendations. 

[00068] In certain circumstances, the network-based commerce system 
10 may not generate the listings recommendation table 290 for a particular user. 
For example, a user might not have a listing recommendation table 290 if: 

• The user has explicitly opted out; 

• The user has opted in but there are no saved recommendation queries 
currently for the particular user; and 

• The user has opted in and there are recommendation queries for the 
particular user, but those queries return zero results. 

[00069] As mentioned above, the exemplary graphic user interface 292 
only shows a limited number of recommended listings generated by each 
recommendation query. In order to provide the user with more 
recommendation queries, the user interface 292 includes a "show me more" links 
356 associated with the recommended listings provided in rows 294 to 302 (see 
Figure 13). In one embodiment, clicking or activating a "show me more" link 356 
will run exactly the same recommendation query that was run to generate the 
listing recommendation currently displayed in the particular row 294 to 302 to 
the user. However, all results (as opposed to only one recommended listing) 
generated as a result of the query initiation via the "show me more" link 356 will 
be returned. 

[00070] Figure 15 shows a diagrammatic representation of a machine 
in the exemplary form of a computer system 400 within which a set or sequence 
of instructions, for causing the machine to perform any one of the methodologies 
discussed herein, may be executed. In alternative embodiments, the machine 
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may comprise a network router, a network switch, a network bridge, Personal 
Digital Assistant (PDA), a cellular telephone, a web appliance, set-top box (STB) 
or any machine capable of executing a sequence of instructions that specify 
actions to be taken by that machine. 

[00071] The computer system 400 includes a processor 402, a main 
memory 404 and a static memory 406, which communicate with each other via a 
bus 408. The computer system 400 may further include a video display unit 410 
(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer 
system 400 also includes an alphanumeric input device 412 (e.g., a keyboard), a 
cursor control device 414 (e.g., a mouse), a disk drive unit 416, a signal 
generation device 418 (e.g., a speaker) and a network interface device 420 to 
interface the computer system to a network 422. 

[00072] The disk drive unit 416 includes a machine-readable 
medium 424 on which is stored a set of instructions or software 426 embodying 
any one, or all, of the methodologies described herein. The software 426 is also 
shown to reside, completely or at least partially, within the main memory 404 
and/ or within the processor 402. The software 426 may further be transmitted or 
received via the network interface device 420. For the purposes of this 
specification, the term "machine-readable medium" shall be taken to include any 
medium which is capable of storing or encoding a sequence of instructions for 
execution by the machine and that cause the machine to perform any one of the 
methodologies of the present invention. The term "machine-readable medium" 
shall accordingly be taken to included, but not be limited to, solid-state 
memories, optical and magnetic disks, and carrier wave signals. Further, while 
the software is shown in Figure 15 to reside within a single device, it will be 
appreciated that the software 426 could be distributed across multiple machines 
or storage media, which may include the machine-readable medium. 
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[00073] Thus, a method and system to recommend listings of a 
network-based commerce system 10 have been described. Although the 
invention has been described with reference to specific exemplary embodiments, 
it will be evident that various modifications and changes may be made to these 
embodiments without departing from the broader spirit and scope of the 
invention. Accordingly, the specification and drawings are to be regarded in an 
illustrative rather than a restrictive sense. 
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